tatanka/trade: add order compatibility and matching functions #3165
Conversation
| // MinFeeRate: Tatankanet does not prescribe a fee rate on an order, but it | ||
| // does supply a suggested fee rate that is updated periodically. The user's | ||
| // UI should ignore an order from the order book if its MinFeeRate falls | ||
| // below the Tatnkanet suggested rate. | ||
| MinFeeRate uint64 `json:"minFeeRate"` |
There was a problem hiding this comment.
This shouldn't be part of the order. This is a dynamic quantity based on the mesh's fee rate oracle service, and only needs to be confirmed as part of the match request sent to the counterparty.
buck54321
force-pushed
the
tanka-order-validate
branch
from
1994ddf to
83e57fd
Compare
tatanka/client/trade/compat.go
Outdated
| ReasonTheirQtyTooSmall = "their order size is less than our lot size" | ||
| ) | ||
|
|
||
| // OrderIsMatchable determines whether a given standling limit order is |
There was a problem hiding this comment.
| // OrderIsMatchable determines whether a given standling limit order is | |
| // OrderIsMatchable determines whether a given standing limit order is |
| // ## Dividing both size by qty | ||
| // 1 / lot_size < max_fee_exposure / (base_fees_per_lot + (quote_fees_per_lot / rate)) | ||
| // ## Fliparoo | ||
| // lot_size > (base_fees_per_lot + (quote_fees_per_lot / rate)) / max_fee_exposure |
There was a problem hiding this comment.
The conclusion is already pretty intuitive.
| // 1 / lot_size < max_fee_exposure / (base_fees_per_lot + (quote_fees_per_lot / rate)) | ||
| // ## Fliparoo | ||
| // lot_size > (base_fees_per_lot + (quote_fees_per_lot / rate)) / max_fee_exposure | ||
| atomicRate := float64(msgRate) / calc.RateEncodingFactor |
There was a problem hiding this comment.
I remember we were discussing changing RateEncodingFactor to be more flexible.
There was a problem hiding this comment.
I'm still open to that. I've always tried to avoid math/big, but I'm starting to soften on that stance. Do you think we should pass around rates as float strings and convert to big types when needed? Let's chat on Matrix.
tatanka/tanka/swaps.go
Outdated
| return blake256.Sum256(b) | ||
|
|
||
| } | ||
|
|
||
| func (ord *Order) Valid() error { | ||
| // Check whether the lot size is a power of 2, using binary ju-jitsu. |
There was a problem hiding this comment.
| // Check whether the lot size is a power of 2, using binary ju-jitsu. | |
| // Check whether the lot size is a power of 2, using binary jiu-jitsu. |
tatanka/tanka/swaps.go
Outdated
| if ord.Rate == 0 { | ||
| return errors.New("order rate is zero") | ||
| } | ||
| if ord.Expiration.Equal(ord.Stamp) || ord.Expiration.Before(ord.Stamp) { |
There was a problem hiding this comment.
| if ord.Expiration.Equal(ord.Stamp) || ord.Expiration.Before(ord.Stamp) { | |
| if !ord.Stamp.After(ord.Expiration) { |
There was a problem hiding this comment.
If the match falls through will that go directly to the books? There would be stages to falling through, initially the counterparty could just say no I assume? In that case it might go the books, but if a trade started and failed after that, maybe we would get a notification and error and it doesnt go to the order book?
This should give us some direction for how trading will work.
Depending on the stage at which the match fails, a failed match would go to either the book or it might be able to generate a new match with the next best compatible standing order. If the match fails after we have already broadcast txs though, we probably wouldn't auto-retry without some kind of user acknowledgement. |
buck54321
force-pushed
the
tanka-order-validate
branch
from
83e57fd to
709c968
Compare
This should give us some direction for how trading will work.